home *** CD-ROM | disk | FTP | other *** search
/ Linux Cubed Series 7: Sunsite / Linux Cubed Series 7 - Sunsite Vol 1.iso / system / network / admin / xinetd.2 / xinetd / xinetd.2.1.7-linux.4 / README.SBC < prev    next >
Encoding:
Text File  |  1996-01-24  |  5.0 KB  |  164 lines
  1.  
  2.                              SBC Additions to xinetd
  3.                              -----------------------
  4.  
  5.                                   Nigel Verdon, 
  6.                              verdenn@gb.swissbank.com
  7.  
  8.                                  7 June 1995
  9.  
  10.  
  11.  
  12. 1. Introduction
  13. ---------------
  14. xinetd is a "drop in" replacement for inetd which allows much more 
  15. control over how services are started/controlled - see the xinetd
  16. documentation for more details.
  17.  
  18. An additional parameter has been added to the xinetd configuration file
  19. to allow a service to be bound to a specific interface.  Therefore we
  20. can control explicitly which services are offered on which interfaces on 
  21. a firewall.  This facility works for tcp, udp and rpc based services.
  22.  
  23. The modifications have only been tested on SunOS 4.1.3_U1.
  24.  
  25. The rational behind modifying xinetd to offer services on specific
  26. interfaces was to allow:
  27.  
  28. 1. firewalls to be designed which allow explicit control over services 
  29.    offered.  This is to prevent people "port scanning" your firewall and 
  30.    obtaining "useful" information for attacks.
  31.  
  32. 2. to be able to bind services which are only required locally on a
  33.    firewall to the looback interface (e.g. the TIS firewall toolkit
  34.    authentication server) and never publish on external interface (
  35.    again to prevent port-scanning).  
  36.  
  37. 3. Internet service providers to offer "vitrual domains" for FTP,
  38.    archie, telnet, WWW (if started via xinetd) etc. etc.
  39.  
  40. If you are intending using this facility on a machine (e.g. a firewall
  41. offering telnet proxy connections to the internal interface and not from 
  42. the external interface - assuming two interfaces) the host MUST HAVE
  43. IP FORWARDING SWITCHED OFF and perform no routing function - otherwise it
  44. is a simple matter to connect to the service on the internal interface 
  45. from an untrusted interface.
  46.  
  47. If you must route packets then use a packet filter on each interface on
  48. your host to prevent such attacks happening.  A suitable package would be
  49. ip_fil by Darren Reed (avalon@coombs.anu.edu.au).
  50.  
  51. 2. Configuration
  52. ----------------
  53. The parameter to specify which interface a service binds to is
  54. called:
  55.  
  56.     interface
  57.  
  58. and is of the following format:
  59.  
  60.     interface x.x.x.x
  61.  
  62. where x.x.x.x is a valid IP address or 0.0.0.0 (which specifies the
  63. service should be bound to all interfaces).  If the "interface" option
  64. is not given for a service the default behaviour is to bind to 0.0.0.0.
  65.  
  66. See the xinetd documentation for more details on configuring services.
  67.  
  68.  
  69. 3. Configuration Examples
  70. -------------------------
  71. Suppose we wanted to configure xinetd to:
  72.  
  73.  - accept telnet connections on interface 128.1.1.1 only from 
  74.    host 128.1.1.3.
  75.  
  76.  - accept telnet connections on interface 155.145.105.3 from 
  77.    any host on the 155.145.105 subnet.
  78.  
  79. - only allow "internal" services (chargen, echo etc.) on the 
  80.   loopback interface 127.0.0.1.
  81.  
  82. the xinetd configuration file to give us this functionality 
  83. would be:
  84.  
  85. #
  86. # Telnet service on 128.1.1.1 interface
  87. #
  88. service telnet
  89. {
  90.     id            = telnet_128
  91.     socket_type   = stream
  92.     wait          = no
  93.     user          = root
  94.     server        = /usr/etc/in.telnetd
  95.     interface     = 128.1.1.1
  96.     only_from     = 128.1.1.3
  97. }
  98.  
  99. #
  100. # Telnet service on 155.145.105.3 interface
  101. #
  102. service telnet
  103. {
  104.     id            = telnet_155
  105.     socket_type   = stream
  106.     wait          = no
  107.     user          = root
  108.     server        = /usr/etc/in.telnetd
  109.     interface     = 155.145.105.3
  110.     only_from     = 155.145.105.0
  111. }
  112.  
  113. #
  114. # Internal echo service
  115. #
  116. service echo
  117. {
  118.     id            = echo-stream
  119.     type          = INTERNAL
  120.     socket_type   = stream
  121.     wait          = no
  122.     user          = root
  123.     interface     = 127.0.0.1
  124. }
  125.  
  126. #
  127. # Internal echo service
  128. #
  129. service echo
  130. {
  131.     id            = echo-dgram
  132.     type          = INTERNAL
  133.     socket_type   = dgram
  134.     wait          = no
  135.     user          = root
  136.     interface     = 127.0.0.1
  137. }
  138.  
  139. Please note that the above example shows how to configure xinetd
  140. to offer "differently configured telnets" by using the "id" tag.
  141. Without the "id" tag xinetd will refuse to start more than one 
  142. instance of a service.
  143.  
  144. 4. Notes
  145. --------
  146. 4.1 If an invalid IP address is given the service will be disabled.
  147.  
  148. 4.2 Changing a service's IP address and sending a SIGHUP signal to
  149.     xinetd will cause all existing services bound to the original
  150.     address to be killed.
  151.  
  152. 4.3 We recommend all logging is done via syslog rather than explicit files
  153.     to prevent file access attacks via symbollic links.  The file opening
  154.     code should really be modified to prevent this (perhaps the next project).
  155.  
  156.     This note is from Chuck Murcko <chuck@telebase.com>:
  157.     The current release of xinetd-2.1.7 logs a warning to the syslog
  158.     LOG_WARNING facility if a logfile is found to be a symlink. Please be
  159.     aware that, in general, you are in serious trouble if your xinetd logs
  160.     get changed to symlinks, as root permission is usually required to do
  161.     this. To monitor runtime state changes to the logfiles, a separate
  162.     daemon would be a better answer than added code in xinetd which can
  163.     impact performance on heavily loaded systems.
  164.